1. Field of the Invention
This invention is related to the field of integrated circuit development software, and particularly to timing software.
2. Description of the Related Art
Static timing analysis tools are used to estimate the delays on various timing paths through digital circuit designs. The resulting timing reports are analyzed by the designers to identify timing paths in the design which do not meet the timing goals of the digital circuit, and the designers attempt to change the design so that the design will meet the timing goals.
More recently, digital circuit designs (e.g. designs to be fabricated on a single integrated circuit) have increased in size and complexity as the number of transistors that may be fabricated on a single integrated circuit has increased. As the size of the design has increased, the size has exceeded the capability of various timing analysis tools to analyze the design in its entirety. Designers have responded by dividing the circuit designs into partitions, each of which can be handled by the timing analysis tools (and other integrated circuit design tools such as synthesis tools, layout tools, etc.). As used herein, a partition is a representation of a portion of the overall circuit, and has defined inputs and outputs. The inputs may be sourced by other partitions, or may be inputs of the overall circuit. The outputs may be supplied to other partitions, may be outputs of the overall circuit, or both.
FIG. 1 is a block diagram illustrating a portion of one embodiment of a design flow that includes timing analysis. Once the circuit design has been divided into one or more partitions, the designer may code a register-transfer level (RTL) description of each partition (reference numeral 10). Any hardware design language (HDL) may be used as the language for the RTL description (e.g. VHDL, Verilog, etc.). The RTL description may comprise one or more files per partition, as desired.
The designer may choose to use a synthesis tool to synthesize the RTL description to a netlist (reference numeral 12). The synthesis tool takes the RTL description and a library of cells (predesigned circuits which have one or more inputs and produce one or more outputs as a specified function of one or more inputs) and generates a netlist of cells, linked together in such a way as to provide the functionality described in the RTL description. On the other hand, the designer may choose to design the circuits manually, using a circuit schematic/schematic capture tool (reference numeral 14). The designer may use a combination of circuit schematic design and synthesis for a given partition.
The resulting netlists and schematic capture data may be provided to a timing analysis tool to estimate the timing of the design (i.e. to estimate whether or not the design will meet timing requirements for the circuit to operate at a desired clock frequency) (reference numeral 16). Based on the timing results, the designer may modify the RTL description and/or the circuit schematics to improve the timing (illustrated in FIG. 1 with the dotted lines from the timing analysis (reference numeral 16) to the RTL coding (reference numeral 10) and the circuit schematics (reference numeral 14)). At the point illustrated by reference numeral 16, delay from the nets interconnecting the cells and other circuitry may be estimated (since the layout has not yet been performed) rather than extracted.
At some point, the estimated timing calculated at reference numeral 16 may be near the timing goals for the integrated circuit, and the layout of the netlists may be performed (reference numeral 18). Alternatively, layout work may start in parallel with timing analysis, or may be performed before any timing analysis is performed, as desired. Generally, the layout includes placing the cells called out in the netlist into physical positions within the integrated circuit layout, and routing the nets which interconnect the cells using the wiring layers of the integrated circuit layout. The circuit schematics produced using the circuit schematic tools may already be laid out within the circuit, but may be placed within the overall layout and the inputs and outputs of the circuit may be connected to nets, similar to the cells.
The timing analysis tool may be executed again (reference numeral 20), using wire delays for the nets extracted from the integrated circuit layout. If timing goals are still not met, additional layout work, RTL coding, or schematic work may be used to improve timing (dotted lines from reference numeral 20 to reference numerals 10, 14, and 18). Once the timing goals are met, the design flow may continue toward fabricating the integrated circuit (not shown).
One embodiment of an exemplary circuit 30 is shown in FIG. 2, having multiple partitions (e.g. partition A 32A, partition B 32B, and partition C 32C illustrated in FIG. 2). Various timing paths are illustrated in FIG. 2 within the partitions 32A–32C. The direction of signal flow in FIG. 2 is from left to right. Generally, a timing path is a path through various circuitry in a partition (or among multiple partitions). The timing path may have an associated delay estimated by a timing analysis tool. The delay may or may not be short enough to meet the timing goals of the circuit 30.
In FIG. 2, various net names (that is, names used to represent nets in the circuit, wherein a net is an interconnecting signal that may be implemented with conductors on the integrated circuit) are illustrated as various letters. Capital letters are net names that are either partition inputs, partition outputs, or state points (controlled by clocks). Lower case letters illustrate net names that are the output of combinatorial logic circuits within the paths. Thus, in FIG. 2, the partition 32A includes a timing path 34A from a state point W through nets x and y to an output A (which is an input to the partition 32B). The partition 32B includes a timing path 34B from the input A through nets b and c to the state point D and continuing through nets e and f to an output G. Additionally, a timing path 34C is shown in the partition 34C from the input A through nets h, i, j, and k to the output G. Finally, a timing path 34D is shown in the partition 32C from the input G through nets l, m, n, and o to a state point P and continuing to an output Q. Generally, a state point is any point at which state may be captured according to a clock (e.g. a flop, register, latch, etc.). The timing paths 34A, 34B, and 34D together form a global timing path in the circuit 30, as do the timing paths 34A, 34C, and 34D.
A timing analysis of each of the timing paths 34A–34D would include the delays between each net in the path, thus supplying the designer with details permitting the rapid identification of circuitry which may be changed to improve the overall timing of the paths. However, to analyze the global timing paths in the circuit 30, a timing analysis of the circuit 30 is needed. While the timing paths 34A–34D may each individually appear to be short, a global timing path formed from the timing paths may not meet timing goals. As mentioned above, a timing analysis of the circuit 30 may be too large to perform using the detailed timing paths within each partition 32A–32C. A detailed timing path includes the intermediate details of delays through circuitry within a partition 32A–32C. On the other hand, an abstract model of each partition may be generated. The abstract model may eliminate some of the details from the detailed timing paths to generate corresponding abstracted timing paths. Thus, an abstracted timing path is a timing path which represents the delay of the timing path but which omits at least some details of the timing path.
For example, in some embodiments, an abstracted timing path may retain partition inputs, outputs, and state points. The abstracted timing path may include delays between the inputs, outputs, and state points. The delays in the abstracted timing paths may be the sum of the delays attributed to the underlying circuitry and interconnect delay, for the worst case delay from the input (or state point) to the output (or state point). Abstracted timing paths that retain partition inputs, partition outputs, and state points are sometimes referred to as gray models. In other embodiments, black models may be used (which retain partition inputs and partition outputs but not state points).
Since the abstract models of each partition include less information, the models are smaller and thus a timing analysis of the circuit 30 may be performed by the timing analysis tool using the abstract models. Unfortunately, however, the timing reports for the circuit 30 include only the abstracted timing paths. Designers desiring more information must look elsewhere than the timing reports generated for the circuit 30. Generally, a timing report is a list of timing paths and the estimated delays on those timing paths.
FIG. 3 is a flowchart illustrating one embodiment of timing analysis for the circuit 30. The flowchart of FIG. 3 may illustrate the general operation of any of a variety of timing analysis tools that may be available commercially (e.g. PathMill available from Synopsys, Inc. of Mountain View, Calif.) as well as other activity performed during timing analysis.
The timing analysis tool may generate an abstract model and a partition debug model for each of the partitions (block 40), using timing analysis at the partition level to identify the timing paths to be retained in the abstract model. That is, the timing path causing the worst case delay from an input (or state point) to a state point or output is retained in the abstract model, and other timing paths from the input to the same state point or output are abstracted out. Additionally, the retained timing path is abstracted from its detailed form (e.g. the form shown in FIG. 2) to a delay from the input (or state point) to the state point or output, eliminating intermediate nets generated by combinatorial logic within the timing path. The abstracted timing path retains enough information to estimate timing delays for the circuit 30 as a whole, but does not retain the detailed information for each timing path within the partition. The partition debug model may include the details of the retained timing paths, but does not include the details of the timing paths which were not retained. For example, if the path 34B is longer than the path 34C in FIG. 2, the path 34C may not be included in the partition debug model.
An example of an abstract model 60 for partition 32B is illustrated in FIG. 4 (assuming that the path 34B is retained and the path 34C is not retained). The path 34B may be abstracted to three “arcs” having corresponding delays in this example: A first arc having a delay D1 from the input A to the state point D, a second arc having the delay D2 from the state point D to the output G, and a third arc having the delay D3 from the clock controlling the state point D to the output G. The delay D1 may thus be the sum of the delays from the input A to the net b, from the net b to the net c, and from the net c to the state point D. Similarly, the delay D2 may be the sum of the delays from the state point D to the net e, from the net e to the net f, and from the net f to the output G; and the delay D3 may be the sum of the delays from the clock (clk) to the state point D, from the state point D to the net e, from the net e to the net f, and from the net f to the output G. Each arc is represented by an entry in the abstract model.
The abstract model may also include a path number for each arc (e.g. represented by the labels Path1 and Path2 in the abstract model of FIG. 4). While a path number is used herein, in general a path identifier of any type may be used (e.g. a number, an alphanumeric string, etc.). The path number may be a value generated by the timing analysis tool to identify a corresponding detailed timing path in the partition debug model. Generally, the form of each entry in the abstract model may vary from timing analysis tool to timing analysis tool. Typically, entries in the abstract model may include at least the net names of the beginning and end of each abstracted path, the delay, and the path number.
An exemplary partition debug model 62 is illustrated in FIG. 5. For each path number, detailed timing path information is maintained. For example, Path1 may include the path from input A to net b, from net b to net c, etc. up to the path from net f to output G. Path2 may include the path from the clock to the state point D, from the state point D to net e, etc. up to the path from the net f to output G. The detailed path may include any desired information. For example, in FIG. 5, the circuit responsible for the delay may be identified, as well as the delay. Any other information may be retained as desired.
Returning to FIG. 3, the timing analysis tool may perform a timing analysis at the circuit level using the abstract models of each partition (block 42). The timing analysis tool may generate a circuit-level timing report, identifying abstracted paths through one or more partitions of the circuit 30 which do not meet the timing goals of the circuit 30 (block 44). The circuit level timing report may identify problematic global timing paths, but does not include the detailed information of the timing paths. Thus, a designer must refer to one or more debug models to find the details of the timing paths. Furthermore, only the worst case timing paths within a partition are retained, and thus other timing paths which may require fixing are not identified.
Additionally, the timing analysis tool may generate timing constraints for the partition inputs and outputs (block 46). Generally, a timing constraint is an indication of the estimated timing of a partition input or output based on the circuit level analysis. For partition inputs, the timing constraint may be a valid time indicating when the partition input is valid (e.g. a starting point for measuring path delay within the partition for paths that include the input). The valid time may be caused by the worst case timing path from other partitions to the partition input. For partition outputs, the constraint may be a required time by which the partition output is to be generated (if timing goals are to be met). The required time may be caused by the worst case timing path that the partition output feeds. The timing constraints may be written to a constraint file which may be used in partition-level timing analysis to identify timing paths in the partitions which are part of a problematic global timing path.
The timing constraints may then be input to the timing analysis tool along with each partition to generate partition-level timing reports (block 50). If the circuit 30 meets timing goals (decision block 52, yes leg), the timing analysis is complete. If the circuit 30 does not meet timing goals (decision block 52, no leg), the designer may examine the timing reports, make changes to improve timing, and begin the timing analysis again with the changed incorporated (block 54).
The partition-level timing reports may include detailed timing paths for the partition, as well as the timing constraints from the constraint file. Thus, the designer may have visibility, in the partition-level timing reports, to not only the worst case timing paths but also other timing paths that may have lower delay but may also need timing improvement to meet timing goals. However, the designer does not have visibility, in the partition-level timing reports, to details of the global timing paths of which a given local partition timing path may be a part. In some cases, it may be more profitable to implement changes in another partition to ease a timing constraint rather than to make changes within the partition.
An exemplary constraint file 64 is shown in FIG. 6. In the example of FIG. 6, a valid constraint t1 is assigned to the partition input A (for the partition 32B) and a required time t2 is assigned to the partition output G (for the partition 32B). Net A is also a partition output (of the partition 32A) in this example, and thus may also have a valid time constraint assigned for the partition 32A (not shown in FIG. 6). Similarly, net G is also a partition input (of the partition 32C) and thus may also have a required time constraint assigned for the partition 32C (not shown in FIG. 6). For each timing constraint, a path number may be included to identify the timing path that causes the timing constraint. For example, the valid timing constraint for the partition input A may be caused by path number Path3, and the required timing constraint for the partition output G may be caused by the path number Path4. The path numbers may refer to paths listed in a constraint debug model, described below.
The timing analysis tool may also generate a constraint debug model (block 48). The constraint debug model may include details of the timing paths which cause the timing constraints in the timing constraint file 64. An exemplary constraint debug model 66 is shown in FIG. 7. In the example of FIG. 7, Path3 may be the path from the state point W to net A in the partition 32A, generating a valid time constraint on the partition input A to the partition 32B. Path4 may be the path from G to P in the partition 32C, generating a required time constraint for the partition output G of the partition 32B. The constraint debug model may also include any other desired information (e.g. the delay for the path).
Since the constraint debug model is generated from the circuit level timing analysis, the timing paths listed in the constraint debug model may be abstracted timing paths. The corresponding detailed timing paths may be available in the partition debug models. Thus, the constraint debug model may include an identifier of the partition that contains the timing path and the path number in the partition debug model of the path. The designer may then examine the partition debug models to find the detailed path information for the timing path that causes a given timing constraint.